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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by IMS Network Testing (INT). 

The present document is part 1 of a multi-part deliverable covering the IMS specific use of Session Initiation Protocol 
(SIP) and Session Description Protocol (SDP); Conformance Testing, as identified below: 

Part 1: "Protocol Implementation Conformance Statement (PICS)"; 

Part 2: "Test Suite Structure (TSS) and Test Purposes (TP)" ; 

Part 3: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) 
proforma specification" . 



Introduction 

To evaluate protocol conformance of a particular implementation, it is necessary to have a statement of which 
capabilities and options have been implemented for a telecommunication specification. Such a statement is called a 
Protocol Implementation Conformance Statement (PICS). 
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Scope 



The present document provides the Protocol Implementation Conformance Statement (PICS) proforma for the IP 
Multimedia core network Subsystem (IMS) equipment supporting the Internet Protocol (IP) multimedia call control 
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) as specified in 
ES 283 003 [1] in compliance with the relevant requirements and in accordance with the relevant guidance given in 
ISO/IEC 9646-7 [4] and ETS 300 406 [5]. 

The supplier of a protocol implementation which is claimed to conform to ES 283 003 [1] is required to complete a 
copy of the PICS proforma provided in annex A of the present document and is required to provide the information 
necessary to identify both the supplier and the implementation. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 283 003 (V2.5.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 
[3GPP TS 24.229 [Release 7], modified]". 

[2] IETF RFC 3261 (2002): "SIP: Session Initiation Protocol". 

[3] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 1: General concepts". 

[4] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[5] ETSI ETS 300 406: "Methods for testing and Specification (MTS); Protocol and profile 

conformance testing specifications; Standardization methodology". 

[6] IETF RFC 5009: "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 

Authorization of Early Media" . 

[7] IETF RFC 5389: "Session Traversal Utilities for NAT (STUN)". 
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2.2 



Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in ES 283 003 [1] and the following apply: 

PICS proforma: document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite 
specifier, which, when completed for an OSI implementation or system, becomes the PICS 

NOTE: See ISO/IEC 9646-1 [3]. 

Protocol Implementation Conformance Statement (PICS): statement made by the suppHer of an Open Systems 
Interconnection (OSI) implementation or system, stating which capabilities have been implemented for a given OSI 
protocol 

NOTE: See ISO/IEC 9646-1 [3]. 

static conformance review: review of the extent to which the static conformance requirements are met by the lUT, 
accomplished by comparing the PICS with the static conformance requirements expressed in the relevant standard(s) 

NOTE: See ISO/IEC 9646-1 [3]. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

B2BUA Back-to-Back User Agent 

CSCF Call Session Control Function 

E-CSCF Emergency CSCF 

FQDN Fully Qualified Domain Name 

IBCF Interconnection Border Control Function 

I-CSCF Interrogating CSCF 

IMS IP Multimedia Subsystem 

IMS-AKA IMS-Authentication and Key Agreement 

IP Internet Protocol 

P-CSCF Proxy CSCF 

PICS Protocol Implementation Conformance Statement 

S-CSCF Serving CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

TLS Transport Layer Security 

UE User Equipment 
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Conformance 



A PICS proforma which conforms to this PICS proforma specification shall be technically equivalent to annex A, and 
shall preserve the numbering and ordering of the items in annex A. 

A PICS which conforms to this PICS proforma specification shall: 

a) describe an implementation which claims to conform to ES 283 003 [1]; 

b) be a conforming ICS proforma which has been completed in accordance with the instructions for completion 
given in clause A. 1 ; 

c) include the information necessary to uniquely identify both the supplier and the implementation. 
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Annex A (normative): 
PICS proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the PICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed PICS proforma. 



A.1 Guidance for completing the ICS proforma 



A.1 .1 Purposes and structure 



The purpose of this PICS proforma is to provide a mechanism whereby a supplier of an implementation of the 
requirements defined in relevant specifications may provide information about the implementation in a standardised 
manner. 

The PICS proforma is subdivided into clauses for the following categories of information: 

instructions for completing the PICS proforma; 

identification of the implementation; 

identification of the protocol; 

PICS proforma tables (for example: Major capabilities, etc). 

A.1 .2 Abbreviations and conventions 

This annex does not reflect dynamic conformance requirements but static ones. In particular, a condition for support of 
a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of a parameter) but the 
capability of the implementation to support the parameter. 

In the sending direction, the support of a parameter means that the implementation is able to send this parameter (but it 
does not mean that the implementation always sends it). 

In the receiving direction, it means that the implementation supports the whole semantic of the parameter that is 
described in the main part of this specification. 

As a consequence, PDU parameter tables in this annex are not the same as the tables describing the syntax of a PDU in 
the reference specification. 

The PICS proforma contained in this annex is comprised of information in tabular form in accordance with the 
guidehnes presented in ISO/IEC 9646-7 [4]. 

Item column 

The item column contains a number which identifies the item in the table. 

Item description column 

The item description column describes in free text each respective item (e.g. parameters, timers, etc.). It implicitly 
means "is <item description> supported by the implementation?". 

Reference column 

The reference column gives reference to the relevant sections in core specifications. 



ETSI 



ETSI TS 102 790-1 VI. 1.1 (2010-03) 



Status column 

The various status used in this annex are in accordance with the rules in table A. 1 . 

Table A.1 : Key to status codes 



Status code 


Status name 


Meaning 


m 


mandatory 


the capability shall be supported. It is a static view of the fact that the 
conformance requirements related to the capability in the reference 
specification are mandatory requirements. This does not mean that a given 
behaviour shall always be observed (this would be a dynamic view), but that it 
shall be observed when the implementation is placed in conditions where the 
conformance requirements from the reference specification compel it to do so. 
For instance, if the support for a parameter in a sent PDU is mandatory, it does 
not mean that it shall always be present, but that it shall be present according 
to the description of the behaviour in the reference specification (dynamic 
conformance requirement). 





optional 


the capability may or may not be supported. It is an implementation choice. 


n/a 


not applicable 


it is impossible to use the capability. No answer in the support column is 
required. 


c.<integer> 


conditional 


the requirement on the capability ("m", "o", "n/a") depends on the support of 
other optional or conditional items. <integer> is the identifier of the conditional 
expression. 


o.<integer> 


qualified optional 


for mutually exclusive or selectable options from a set. <integer> is the identifier 
of the group of options, and the logic of selection of the options. 



Mnemonic column 

The Mnemonic column contains mnemonic identifiers for each item. 

Support column 

The support column shall be filled in by the supplier of the implementation. The following common notations, defined 
in ISO/IEC 9646-7 [4], are used for the support column: 

Y or y supported by the implementation 

N or n not supported by the implementation 

N/A, n/a or - no answer required (allowed only if the status is N/A, directly or after evaluation of a conditional 
status) 



References to items 

For each possible item answer (answer in the support column) within the PICS proforma there exists a unique reference, 
used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", 
followed by the item number in the table. 



EXAMPLE: 



A. 5/4 is the reference to the answer of item 4 in table A. 5. 



A.1 .3 Instructions for completing the PICS proforma 

The supplier of the implementation may complete the PICS proforma in each of the spaces provided. More detailed 
instructions are given at the beginning of the different clauses of the PICS proforma. 



A.2 Identification of the Network Equipment 

Identification of the Network Equipment should be filled in so as to provide as much detail as possible regarding 
version numbers and configuration options. 

The product supplier information and client information should both be filled in if they are different. 
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A person who can answer queries regarding information supplied in the PICS should be named as the contact person. 

A.2.1 Date of the statement 

A.2.2 Network Equipment Under Test identification 

Name: 

Hardware configuration: 



Software configuration: 



A.2.3 Product supplier 

Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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A.2.4 Client 

Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 



A.2.5 PICS contact person 

Name: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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A.3 Identification of the protocol 

This PICS proforma applies to the following specification: 
ES283 003[1]. 



A.4 Global statement of conformance 

The implementation described in this PICS meets all the mandatory requirements of the referenced standard? 



[ ] Yes 



[ ]No 



NOTE: Answering "No" to this question indicates non-conformance to the protocol specification. Non- supported 
mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is 
non-conforming. Explanations may be entered in the comments field at the bottom of each table or on 
attached pages. 

In the tabulations which follow, all references are to ES 283 003 [1] unless another numbered reference is explicitly 
indicated. 



A.5 PICS proforma tables 



A.5.1 Roles 



Table A.2: Roles 



Item 


Roles 


Reference 


Status 


Support 


1 


P-CSCF 


Clause 5.2 


0.1 




2 


l-CSCF 


Clause 5.3 


0.1 




3 


S-CSCF 


Clause 5.4 


0.1 




4 


IBCF 


Clause 5.10 


0.1 




5 


E-CSCF 


Clause 5.11 


0.1 




0.1 At least one of these capabilities shall be supported. 



A.5.2 P-CSCF Role 

The tables provided in this clause need only to be completed for P-CSCF implementations, where item A.2/1 above is 
supported. 
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A.5.2.1 P-CSCF Capabilities 



Table A.3: P-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


the proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.2 


m 




1.2 


the proxy role with IMS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.2 


m 




1.3 


the proxy role with IMS related exceptions and 
additional capabilities to SigComp? 


Clauses 4.1, 8.2 


m 




2 


the UA role with IMS related exceptions and 
additional capabilities? 


Clauses 4.1, 5.2 


m 




3.1 


the loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




3.2 


interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] 
Clauses 12.2.1.1, 
16.4 


m 




4 


procedures related to charging? 


Clause 4.5 


m 




P-CSCF specific application usage of SIP (clause 5.2) 


5 


registration with security association set-up? 


Clause 5.2.2 


m 




5.1 


procedures that apply on receipt of a REGISTER 
request from the UE? 


Clause 5.2.2, first 
numbered list 


m 




5.1.1 


rejection of the request in case of failure of the 
verification of the content of the Security-Verify 
headers and Security-Client headers? 


Clause 5.2.2, 
first 6) a) 







5.2 


procedures that apply on receipt of a 401 response 
to a REGISTER request? 


Clause 5.2.2, 
second numbered 
list 


m 




5.3 


procedures that apply on receipt of a 200OK 
response to a REGISTER request? 


Clause 5.2.2, third 
numbered list 


m 




5.4 


parallel management of old and newly established 
security associations? 


Clause 5.2.2, Table 
5.2.2-1 


m 




6 


registration without security association set-up? 


Clause 5.2.2A 


m 




6.1 


procedures that apply on receipt of a REGISTER 
request from the UE? 


Clause 5.2.2A, first 
numbered list 


m 




6.2 


procedures that apply on receipt of a 200OK 
response to a REGISTER request? 


Clause 5.2.2A, 
second numbered 
list 


m 




7 


subscription procedures to a user's registration 
state? (see note 1 ) 


Clause 5.2.3 


m 




8 


procedures of registering additional public user 
identities? (see note 2) 


Clause 5.2.4 


m 




9.1 


procedures for user-initiated deregistration? 


Clause 5.2.5.1 


m 




9.2 


procedures for network-initiated deregistration? 


Clause 5.2.5.2 


m 




10 


handling of requests (other than REGISTER) 
initiated by the UE? 


Clause 5.2.6.3 


m 




10.1 


handling of initial requests? 


Clause 5.2.6.3, first 
numbered list 


m 




10.1.1 


in case of failure of the verification of the URIs in the Route headers (Clause 5.2.6.3 first 1)) ... 


10.1.1.1 


rejection of the request? 


Clause 5.2.6.3 first 
Da) 


0.1 




10.1.1.2 


replacement of the Route headers with stored 
values? 


Clause 5.2.6.3 first 
1)b) 


0.1 




10.1.2 


when building the Via header (Clause 5.2.6.3 first 3)) ... 


10.1.2.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.3 first 
3) a) 


0.2 




10.1.2.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.3 first 
3)b) 


0.2 




10.1.3 


when building the Record-Route header (Clause 5.2.6.3 first 4)) ... 


10.1.3.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.3 first 
4) a) 


0.3 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


10.1.3.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.3 first 
4)b) 


0.3 




10.2 


handling of Ixx and 2xx responses to initial 
requests? 


Clause 5.2.6.3, 
second numbered 
list 


m 




10.2.1 


in case a security association exists, when rewriting its own Record Route entry (clause 5.2.6.3 second 
4))... 


10.2.1.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association? 


Clause 5.2.6.3 
second 4) a) 


0.4 




10.2.1.2 


insertion of the P-CSCF IP address of the security 
association? 


Clause 5.2.6.3 
second 4) b) 


0.4 




10.3 


handling of target refresh requests? 


Clause 5.2.6.3, third 
numbered list 


m 




10.3.1 


in case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3 third 2)) ... 


10.3.1.1 


rejection of the request? 


Clause 5.2.6.3 third 
2) a) 


0.5 




10.3.1.2 


replacement of the Route headers with stored 
values? 


Clause 5.2.6.3 third 
2)b) 


0.5 




10.3.2 


when building the Via header (clause 5.2.6.3 third 3)) ... 


10.3.2.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.3 third 
3) a) 


0.6 




10.3.2.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.3 third 
3)b) 


0.6 




10.3.3 


when building the Record-Route header (clause 5.2.6.3 third 4)) ... 


10.3.3.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.3 third 
4) a) 


0.7 




10.3.3.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.3 third 
4)b) 


0.7 




10.4 


handling of responses to target refresh requests? 


Clause 5.2.6.3, 
fourth numbered list 


m 




10.5 


handling of requests for a standalone transaction? 


Clause 5.2.6.3, fifth 
numbered list 


m 




10.5.1 


in case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3 fifth 1)) ... 


10.5.1.1 


rejection of the request? 


Clause 5.2.6.3 fifth 
1)a) 


0.8 




10.5.1.2 


replacement of the Route headers with stored 
values? 


Clause 5.2.6.3 fifth 
1)b) 


0.8 




10.6 


handling of responses to standalone requests? 


Clause 5.2.6.3, sixth 
numbered list 


m 




10.7 


handling of subsequent (other than target refresh) 
requests? 


Clause 5.2.6.3, sixth 
numbered list 


m 




10.7.1 


in case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3 seventh 1)) ... 


10.7.1.1 


rejection of the request? 


Clause 5.2.6.3 
seventh 1 ) a) 


O.10 




10.7.1.2 


replacement of the Route headers with stored 
values? 


Clause 5.2.6.3 
seventh 1 ) b) 


O.10 




11 


handling of requests terminated by the UE? 


Clause 5.2.6.4 


m 




11.1 


handling of initial requests? 


Clause 5.2.6.4, first 
numbered list 


m 




11.1.1 


when building the URI (clause 5.2.6.4 first 3)) ... 


11.1.1.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.4 first 
3) a) 


0.11 




11.1.1.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.4 first 
3)b) 


0.11 




11.1.2 


when building the Via header (clause 5.2.6.4 first 4)) ... 


11.1.2.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.4 first 
4) a) 


0.12 




11.1.2.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.4 first 
4)b) 


0.12 




11.2 


handling of Ixx and 2xx responses to initial 
requests? 


Clause 5.2.6.4, 
second numbered 
list 


m 




11.2.1 


in case of failure of the verification of the Via headers (clause 5.2.6.4 second 2)) ... 


11.2.1.1 


discarding the response? 


Clause 5.2.6.4 
second 2) a) 


0.13 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


11.2.1.2 


replacement of the Via header values with stored 
values? 


Clause 5.2.6.4 
second 2) b) 


0.13 




11.2.2 


in case of failure of the verification of the URIs in the Route headers (clause 5.2.6.4 second 3)) ... 


11.2.2.1 


discarding the response? 


Clause 5.2.6.4 
second 3) a) 


0.14 




11.2.2.2 


replacement of the Record-Route header values 
with stored values? 


Clause 5.2.6.4 
second 3) b) 


0.14 




11.3 


handling of responses (other than Ixx and 2xx) to 
initial requests? 


Clause 5.2.6.4, third 
numbered list 


m 




11.3.1 


in case of failure of the verification of the Via headers (clause 5.2.6.4 third 1)) ... 


11.3.1.1 


discarding the response? 


Clause 5.2.6.4 third 
Da) 


0.15 




11.3.1.2 


replacement of the Via header values with stored 
values? 


Clause 5.2.6.4 third 
1)b) 


0.15 




11.4 


handling of target refresh requests? 


Clause 5.2.6.4, 
fourth numbered list 


m 




11.4.1 


when building the Via header (clause 5.2.6.4 fourth 1)) ... 


11.4.1.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association? 


Clause 5.2.6.4 
fourth 1)a) 


0.16 




11.4.1.2 


insertion of the P-CSCF IP address of the security 
association? 


Clause 5.2.6.4 
fourth 1)b) 


0.16 




11.4.2 


when building the Record-Route header (clause 5.2.6.4 fourth 2)) ... 


11.4.2.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.4 
fourth 2) a) 


0.17 




11.4.2.2 


insertion of the P-CSCF IP address? 


Clause 5.2.6.4 
fourth 2) b) 


0.17 




11.5 


handling of Ixx and 2xx responses to target 
refresh requests? 


Clause 5.2.6.4, fifth 
numbered list 


m 




11.5.1 


in case of failure of the verification of the Via headers (clause 5.2.6.4 fifth 1 


))... 




11.5.1.1 


discarding the response? 


Clause 5.2.6.4 fifth 
Da) 


0.18 




11.5.1.2 


replacement of the Via header values with stored 
values? 


Clause 5.2.6.4 fifth 
Db) 


0.18 




11.6 


handling of responses (other than Ixx and 2xx) to 
target refresh requests? 


Clause 5.2.6.4, sixth 
numbered list 


m 




11.6.1 


in case of failure of the verification of the Via headers (clause 5.2.6.4 sixth 


D)... 




11.6.1.1 


discarding the response? 


Clause 5.2.6.4 sixth 
Da) 


0.19 




11.6.1.2 


replacement of the Via header values with stored 
values? 


Clause 5.2.6.4 sixth 
Db) 


0.19 




11.7 


handling of requests for standalone transactions or 
unknown methods? 


Clause 5.2.6.4, 
seventh numbered 
list 


m 




11.7.1 


when building the Via header (clause 5.2.6.4 seventh 1)) ... 


11.7.1.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association? 


Clause 5.2.6.4 
seventh 1 ) a) 


O.20 




11.7.1.2 


insertion of the P-CSCF IP address of the security 
association? 


Clause 5.2.6.4 
seventh 1 ) b) 


O.20 




11.8 


handling of all responses to requests for 
standalone transactions or unknown methods? 


Clause 5.2.6.4, 
eighth numbered list 


m 




11.8.1 


in case of failure of the verification of the Via headers (clause 5.2.6.4 eightl' 


1D)... 




11.8.1.1 


discarding the response? 


Clause 5.2.6.4 
eighth 1) a) 


0.21 




11.8.1.2 


replacement of the Via values with stored values? 


Clause 5.2.6.4 
eighth 1)b) 


0.21 




11.9 


handling of subsequent (other than target refresh) 
requests? 


Clause 5.2.6.4, ninth 
numbered list 


m 




11.9.1 


when building the Via header (clause 5.2.6.4 ninth 1)) ... 


11.9.1.1 


insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association? 


Clause 5.2.6.4 ninth 
Da) 


0.22 




11.9.1.2 


insertion of the P-CSCF IP address of the security 
association? 


Clause 5.2.6.4 ninth 
Db) 


0.22 




11.10 


handling of Ixx and 2xx responses to subsequent 
requests? 


Clause 5.2.6.4, tenth 
numbered list 


m 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


11.10.1 


in case of failure of the verification of the Via headers (clause 5.2.6.4 tenth 1)) ... 


11.10.1.1 


discarding the response? 


Clause 5.2.6.4 tenth 
Da) 


0.23 




11.10.1.2 


replacement of the Via header values with stored 
values? 


Clause 5.2.6.4 tenth 
1)b) 


0.23 




12.1 


additional requirements for UE-originated INVITE 
requests? 


Clause 5.2.7.2 


m 




12.1.1 


application of periodic session refreshment on 
receipt of UE-originated INVITE requests? 


Clause 5.2.7.2 







12.2 


additional requirements for UE-terminated INVITE 
requests? 


Clause 5.2.7.3 


m 




12.2.1 


application of periodic session refreshment on 
receipt of UE-terminated INVITE requests? 


Clause 5.2.7.3 







13.1 


P-CSCF initiated call release? 


Clause 5.2.8.1 


m 




13.2 


call release initiated by other entities? 


Clause 5.2.8.2 


m 




13.3 


call release due to session expiry? 


Clause 5.2.8.3 


m 




14.1 


additional requirements for subsequent requests 
(UE-originating case)? 


Clause 5.2.9.1 


m 




14.2 


additional requirements for subsequent requests 
(UE-terminating case)? 


Clause 5.2.9.2 


m 




15 


the emergency service? 


Clauses 5.2.10, 
5.2.10.1,5.2.10.5 


m 




15.1 


requests for all dialogs and standalone 
transactions (other than REGISTER) from an 
unregistered user? 


Clause 5.2.10.2 


m 




15.1.1 


when building the URI (clause 5.2.10.2 1)) ... 


15.1.1.1 


inclusion of the URI received from the UE? 


Clause 5.2.10.2 1) 
first - 


0.24 




15.1.1.2 


inclusion of a URI deduced from the URI received 
from the UE? 


Clause 5.2.10.2 1) 
second - 


0.24 




16.1 


requests for all dialogs and standalone 
transactions (other than REGISTER) from an 
emergency-registered user? 


Clause 5.2.10.3 


m 




16.1.1 


when building the URI (clause 5.2.10.3 1)) ... 


16.1.1.1 


inclusion of the URI received from the UE? 


Clause 5.2.10.3 1) 
first - 


0.25 




16.1.1.2 


inclusion of a URI deduced from the URI received 
from the UE? 


Clause 5.2.10.3 1) 
second - 


0.25 




17.1 


requests for all dialogs and standalone 
transactions (other than REGISTER) from an 
non-emergency-registered user? 


Clause 5.2.10.4 


m 




17.1.1 


when building the URI (clause 5.2.10.4 1)) ... 


17.1.1.1 


inclusion of the URI received from the UE? 


Clause 5.2.10.4 1) 
first - 


0.26 




17.1.1.2 


inclusion of a URI deduced from the URI received 
from the UE? 


Clause 5.2.10.4 1) 
second - 


0.26 




P-CSCF specific application usage of SDP (clause 6.2) 


18.1 


handling of requests including SDP offers? 


Clause 6.2 


m 




18.1.1 


rejection of requests including encrypted SDP 
offers? 


Clause 6.2, first 
paragraph 







18.2 


handling of responses (other than 200OK) 
including SDP offers? 


Clause 6.2, second 
paragraph 


m 




18.2.1 


rejection of requests following non-200OK 
responses including encrypted SDP offers? 


Clause 6.2, second 
paragraph 







18.3 


handling of 200OK responses including SDP 
offers? 


Clause 6.2, third 
paragraph 


m 




18.3.1 


session termination on receipt of encrypted SDP 
offers in 200OK responses? 


Clause 6.2, third 
paragraph 







18.4 


inspection of b=RS and b=RR lines within an SDP 
offer? 


Clause 6.2, eighth 
paragraph 







SIP compression (clause 8.2) 


19 


SIP compression? 


Clauses 8.2.1, 8.2.2 







19.1.1 


SigComp compression including additional 
requirements? 


Clause 8.2.1 


C.I 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


19.1.2 


the negative acknowledgement mechanism for 
compression? 


Clause 8.2.1 







19.2.1 


SIP dictionary for compression? 


Clause 8.2.1 


C.I 




19.2.2 


the presence specific dictionary for compression? 


Clause 8.2.1 







20 


decompression of requests and responses from 
the UE? 


Clause 8.2.3 


m 




IP-Connectivity Access Network specific concepts wlien using xDSL to access IM CN subsystem (Annex E) 


21 


P-CSCF usage of SIP for xDSL access to IM CN 
subsystem? 


Clause E.3.2 


m 




21.1 


insertion of the P-Access-Network-lnfo header 

for location information handling? 


Clause E.3.2. 2 







Additional procedures in support for hosted NAT (Annex F) 


22 


P-CSCF usage of SIP in support for hosted NAT? 


Clause F.2.2 


m 




22.1 


rejection of integrity protected REGISTER requests 
in case the comparison of the Security-Verify 
header and the Security-Server header with 
stored values fails? 


Clause F.2.2, first 
numbered list (6, 
third - 







23 


P-CSCF usage of SDP in support for hosted NAT? 


Clause F.3.2 


m 




24 


P-CSCF usage of SIP in support for hosted NAT in 
case UDP encapsulated IPsec is not employed? 


Clause F.4 


m 




Additional procedures in support of NA(P) T and NA(P) T-PT controlled by the P-CSCF (Annex G) 


25 


P-CSCF usage of SDP in support of NA(P)T and 
NA(P)T-PT? 


Clause G.2 


m 




DOCSIS aspects when connected to the IM CN subsystem (Annex H) 


26 


P-CSCF usage of SIP for connection to the IM CN 
subsystem? 


Clause H.3.2 


m 




26.1 


insertion of the P-Access-Network-lnfo header 

for location information handling? 


Clause H.3.2.2 







Additional procedures in support of UE managed NAT traversal (Annex K) 


27 


additional procedures to registration with security 
association set-up for UE managed NAT traversal? 


Clauses 5.2.2, 
K.2.2.2 


m 




28.1 


additional procedures to handling of requests 
(other than REGISTER) initiated by the UE for UE 
managed NAT traversal? 


Clauses 5.2.6.3, 
K.2.2.3.1 


m 




28.2 


additional procedures to handling of requests 
(other than REGISTER) terminated by the UE for 
UE managed NAT traversal? 


Clauses 5.2.6.4, 
K.2.2.3.2 


m 




29 


requirements for a STUN server? 


Clause K.2.2.4, 
RFC 5389 [7] 


m 




30 


additional procedures to the emergency service for 
UE managed NAT traversal? 


Clause 5.2.10, 
K.2.2.5 


m 




31 


P-CSCF usage of SDP for UE managed NAT 
traversal? 


Clause K.3.2 


m 




31.1 


modification of SDP offers without a candidate 
attribute received from a UE located behind a 
hosted NAT? 


Clause K.3.2.1, 
K.3.2.3 







31.2 


modification of SDP answers without a candidate 
attribute received from a UE located behind a 
hosted NAT? 


Clause K.3.2.1, 
K.3.2.3 







SIP Digest (Annex L) 


32 


SIP Digest? 


Clause L.I, L.2.2 







33 


Transport Layer Security (TLS)? 


Clause L.I 


C.2 




34 


additional procedures to registration with security 
association set-up for SIP Digest? 


Clauses 5.2.2, 
L.2.2.2 


C.2 




35.1 


additional procedures to handling of requests 
(other than REGISTER) initiated by the UE for SIP 
Digest? 


Clauses 5.2.6.3, 
L.2.2.3 


c.2 




35.2 


additional procedures to handling of requests 
(other than REGISTER) terminated by the UE for 
SIP Digest? 


Clauses 5.2.6.4, 
L.2.2.4 


c.2 




36 


additional procedures to the emergency service for 
SIP Digest without TLS? 


Clauses 5.2.10.1, 
L.2.2.5 


C.3 




NOTE 1 : The P-CSCF has to send a SUBSCRIBE request to the home domain in which the user's public user identity 

resides. 
NOTE 2: The P-CSCF is informed of additional public user identities by the registrar via NOTIFY requests. 
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Item 



Major capability: 
Does the implementation support.. 



o.n At least one of these capabilities shall be supported. 

C.1 m, if A.3/19 is supported, else o 

C.2 0, if A.3/32 is supported, else n/a 

C.3 m, if A.3/34 is supported, else n/a 



Reference 



Status 



Support 



A.5.2.2 P-CSCF header handling 



Table A.4: P-CSCF Header Handling 



Item 


Header handling: 
Does the implementation support... 


Reference 


Status 


Support 


1 


the Path header in REGISTER request and 
related 200OK response messages? 


Clause 5.2.1 


m 




2 


the Service-Route header in 200OK response 
messages to REGISTER requests? 


Clause 5.2.1 


m 




3.1 


removal of the P-Charging-Function-Addresses 
header from requests and responses to be sent to 
the UE? 


Clause 5.2.1 


m 




3.2 


removal of the P-Charging-Vector header from 
requests and responses to be sent to the UE? 


Clause 5.2.1 


m 




4.1.1 


removal of the P-Charging-Function-Addresses 
header from requests and responses received 
from the UE? 


Clause 5.2.1 


m 




4.1.2 


insertion of saved P-Charging-Function- 
Addresses header into requests and responses 
from the UE to be forwarded? 


Clause 5.2.1 







4.2.1 


removal of the P-Charging-Vector header from 
requests and responses received from the UE? 


Clause 5.2.1 


m 




4.2.2 


insertion of saved P-Charging-Vector header into 
requests and responses from the UE to be 
forwarded? 


Clause 5.2.1 







4.3.1 


removal of the P-Access-Network header with 
"network provided" parameter? 


Clause 5.2.1 


m 




4.3.2 


insertion of the P-Access-Network header with 
"network provided" parameter? 


Clause 5.2.1 







5 


removal of the P-Media-Authorization header 

from requests and responses to be sent to the UE? 


Clause 5.2.1 


m 




6 


removal, insertion and modification of the 
P-Early-Media header? 


Clause 5.2.1, 
RFC 5009 [6] 


m 
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A.5.3 l-CSCF Role 

The tables provided in this clause need only to be completed for I-CSCF implementations, where item A.2/2 above is 
supported. 



A.5.3. 1 l-CSCF Capabilities 



Table A.5: l-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


the proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.3 


m 




1.2 


the UA role when providing server functionality to 
return a final response? 


Clause 4.1 







2.1 


the loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




2.2 


interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] 
Clauses 12.2.1.1, 16.4 


m 




3 


procedures related to charging? 


Clause 4.5 


m 




l-CSCF specific application usage of SIP (clause 5.3) 


4.1 


procedures that apply on receipt of a REGISTER 
request? (see note 1) 


Clause 5.3.1.2 


m 




4.2 


procedures that apply on receipt of a user 
registration status query response? (Note 2) 


Clause 5.3.1.2 first 
and second 
numbered list 


m 




4.2.1 


insertion of the Redirect-Host AVP into the 
P-User-Database header of the REGISTER 
request to be sent to the S-CSCF? 


Clause 5.3.1.2 first 2), 
second 3) 







4.3.1 


procedures that apply in case the user registration 
status query procedure fails? 


Clause 5.3.1.3 


m 




4.3.2 


procedures that apply on receipt of no response or 
a response other than 200OK from the S-CSCF? 


Clause 5.3.1.3 


m 




5.1 


stateful proxy behaviour for initial requests? 


Clause 5.3.2.1 first 
sentence 


0.1 




5.2 


stateless proxy behaviour for initial requests? 


Clause 5.3.2.1comple 
ment of first sentence 


0.1 




5.3 


handling of initial requests not containing the "orig" 
parameter in the topmost Route header? 


Clause 5.3.2.1 


m 




5.3.1 


application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.3.2.1 







5.3.2 


insertion of the Redirect-Host AVP into the 
P-User-Database header of INVITE requests to 
be forwarded to the S-CSCF? 


Clause 5.3.2.1 
second 3) 







5.4 


originating procedures for requests containing the 
"orig" parameter in the topmost Route header? 


Clause 5.3.2.1A 


m 




5.4.1 


application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.3.2.1A 







5.4.2 


insertion of the Redirect-Host AVP into the 
P-User-Database header of INVITE requests to 
be forwarded to the S-CSCF? 


Clause 5.3.2. 1A 
first 3) 







5.5 


procedures for unsuccessful outcome of request 
processing? 


Clause 5.3.2.2 


m 




NOTE 1 : The l-CSCF has to start the user registration status query procedure on receipt of the REGISTER request 

from the P-CSCF. The l-CSCF shall behave as a stateful proxy. 
NOTE 2: If the user registration status query procedure succeeds, the l-CSCF has to forward the REGISTER request 

to the S-CSCF. The 200OK response from the S-CSCF has to be proxied to the P-CSCF. 
o.n At least one of these capabilities shall be supported. 
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A.5.4 S-CSCF Role 

The tables provided in this clause need only to be completed for S-CSCF implementations, where item A.2/3 above is 
supported. 

A.5.4. 1 S-CSCF Capabilities 

Table A.6: S-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


the proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.4 


m 




1.2 


the proxy role with IMS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.3 


m 




2 


the UA role with IMS related exceptions and 
additional capabilities? (see note) 


Clauses 4.1, 5.4 


m 




3.1 


the loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




3.2 


interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] and 
clauses 12.2.1.1, 
16.4 


m 




4 


procedures related to charging? 


Clause 4.5 


m 




S-CSCF specific application usage of SIP (clause 5.4) 


5 


initial registration and user-initiated re-registration 
with IMS-AKA authentication including the 
abnormal cases? 


Clauses 5.4.1.2, 
5.4.1.2.3 


m 




5.1 


procedures that apply on receipt of an unprotected 
REGISTER request for an already registered 
public user identity? 


Clause 5.4.1.2.1 first 
numbered list 


m 




5.2 


procedures that apply on receipt of an unprotected 
REGISTER request for a not yet registered public 
user identity? 


Clause 5.4.1.2.1 
second numbered 
list 


m 




6 


initial registration and user-initiated re-registration 
for non IMS-AKA authentication including the 
abnormal cases? 


Clauses 5.4.1. 2A, 
5.4.1. 2A.1 


m 




6.1 


procedures that apply on receipt of an unprotected 
REGISTER request for an already registered 
public user identity? 


Clause 5.4.1. 2A first 
numbered list 


m 




6.2 


procedures that apply on receipt of an unprotected 
REGISTER request for a not yet registered public 
user identity? 


Clause 5.4.1. 2A 
second numbered 
list 


m 




7.1 


procedures that apply on receipt of a protected 
REGISTER request for which authentication is 
currently ongoing? 


Clause 5.4.1.2.2 first 
numbered list 


m 




7.1.1 


authentication for all received protected 
REGISTER requests even if authentication is 
currently ongoing? 


Clause 5.4.1.2.2 first 
1) 







7.2 


procedures that apply on receipt of a protected 
REGISTER request for which no authentication is 
currently ongoing? 


Clause 5.4.1.2.2 
second numbered 
list 


m 




8 


user-initiated deregistration? 


Clause 5.4.1.4 


m 




9 


network-initiated deregistration? 


Clause 5.4.1.5 


m 




10 


network-initiated re-authentication? 


Clause 5.4.1.6 


m 




11 


notification of AS about registration status? 


Clause 5.4.1.7 


m 




11.1 


when building the To header of the REGISTER request to the AS (clause 5.4.1 .7 c))... 


11.1.2 


Insertion of a public user identity as contained in 
the REGISTER request received from the UE? 


Clause 5.4.1.7 c) 


0.1 




11.1.2 


Insertion of an implicitly registered public user 
identities from the service profile? 


Clause 5.4.1.7 c) 


0.1 




12 


service profile updates? 


Clause 5.4.1.8 


m 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


12.1 


when receiving a service profile modifying Push-Profile-Request (clause 5.4.1 .8 "dashed" list) ... 


12.1.1 


procedures for notification of the reg-event 
subscribers about the registration state? 


Clause 5.4.1.8 first- 


0.2 




12.1.2 


shortening the life time of the current registration? 


Clause 5.4.1.8 
second - 


0.2 




13 


subscription and notification? 


Clause 5.4.2 


m 




13.1 


procedures that apply on receipt of Subscribe 
requests? 


Clause 5.4.2.1.1 


m 




13.2 


transmission of notifications about the registration 
state? 


Clause 5.4.2.1.2 


m 




14 


handling of requests initiated by the served user? 


Clause 5.4.3.2 


m 




14.1 


handling of the receipt of initial requests for a 
dialog or a standalone transaction from the served 
user? 


Clause 5.4.3.2, first 
numbered list 


m 




14.2 


handling of the receipt of initial requests for a 
dialog or a standalone transaction from an AS 
acting on behalf of an unregistered user? 


Clause 5.4.3.2, 
second numbered 
list 


m 




14.3 


handling of the responses (or the absence of 
responses) to initial requests? 


Clause 5.4.3.2 third 
numbered list 


m 




14.4 


handling of the receipt of target refresh requests 
from the served user? 


Clause 5.4.3.2, 
fourth numbered list 


m 




14.5 


handling of the Ixx and 2xx responses to target 
refresh requests? 


Clause 5.4.3.2, fifth 
numbered list 


m 




15 


handling of requests terminated by the served 
user? 


Clause 5.4.3.3 


m 




15.1 


handling of the receipt of initial requests for a 
dialog or a standalone transaction for the served 
user? 


Clause 5.4.3.3, first 
numbered list 


m 




15.2 


handling of the responses (or the absence of 
responses) to initial requests? 


Clause 5.4.3.3, third 
and fourth 
numbered list 


m 




15.3 


handling of the receipt of initial requests for a 
dialog or a standalone transaction for an 
unregistered user? 


Clause 5.4.3.3, 
second numbered 
list 


m 




15.4 


handling of the receipt of target refresh requests 
for the served user? 


Clause 5.4.3.3, fifth 
numbered list 


m 




15.5 


handling of the Ixx and 2xx responses to target 
refresh requests? 


Clause 5.4.3.3, sixth 
numbered list 


m 




15.6 


handling of the receipt of subsequent requests 
(other than target refresh) for the served user? 


Clause 5.4.3.3, 
seventh numbered 
list 


m 




15.7 


handling of the Ixx and 2xx responses to 
subsequent requests? 


Clause 5.4.3.3 


m 




16 


encoding of the original dialog identifier? 


Clause 5.4.3.4 


m 




17.1 


additional requirements for INVITE requests from 
the served user? 


Clause 5.4.4.1 


m 




17.2 


additional requirements for INVITE requests for the 
served user? 


Clause 5.4.4.1 


m 




17.2.1 


application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.4.4.1 







17.2.2 


examination of the contents of the SDP offer within 
the INVITE requests for the served user? 


Clause 5.4.4.1 







17.2.2.1 


on detection of an unsupported IP address type (clause 5.4.4.1)... 


17.2.2.1.1 


rejection of the requests with a305 response 
towards the l-CSCF? 


Clause 5.4.4.1, first- 


C.I 




17.2.2.1.2 


acceptance and forwarding of the request towards 
the IBCF? 


Clause 5.4.4.1, 
second - 


C.I 




18.1 


additional requirements for subsequent requests 
(UE-originating case)? 


Clause 5.4.4.2.1 


m 




18.1.1 


insertion of previously saved values into the 
P-Charging-Vector header and 
P-Charging-Function-Addresses header of 

requests and responses (other than ACK and 
CANCEL)? 


Clause 5.4.4.2.1, 
third paragraph 







18.2 


additional requirements for subsequent requests 


Clause 5.4.4.2.2 


m 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 




for the served user (UE-terminating case)? 








18.2.1 


insertion of previously saved values into the 
P-Charging-Vector header and 
P-Charging-Function-Addresses header of 

requests and responses (other than ACK and 
CANCEL)? 


Clause 5.4.4.2.2, 
third paragraph 







19.1 


S-CSCF initiated call release? 


Clause 5.4.5.1 


m 




19.2 


call release initiated by other entities? 


Clause 5.4.5.2 


m 




19.3 


call release due to session expiry? 


Clause 5.4.5.3 


m 




20.1 


additional requirements for RelNVITE and 
UPDATE requests (UE-originating case)? 


Clause 5.4.6.1.2 


m 




20.2 


additional requirements for RelNVITE and 
UPDATE requests for the served user 
(UE-terminating case)? 


Clause 5.4.6.1.3 


m 




21 


GRUU management? 


Clause 5.4. 7A 


m 




21.1 


public GRUUs? 


Clause 5.4.7A.2 


m 




21.2 


temporary GRUUs? 


Clause 5.4.7A.3 


m 




21.2.1 


temporary GRUUs without the need for extra 
states? 


Clause 5.4.7A.3 


0.4 




21.2.2 


stateful representation of temporary GRUUs? 


Clause 5.4.7A.3 


0.4 
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emergency services? 


Clause 5.4.8 


m 




S-CSCF specific appiication usage of SDP (ciause 6.3) 


23.1 


handling of requests including SDP offers? 


Clause 6.3 


m 




23.1.1 


rejection of requests including encrypted SDP 
offers? 


Clause 6.3, first 
paragraph 







23.2 


handling of responses (other than 200OK) 
including SDP offers? 


Clause 6.2, second 
paragraph 


m 




23.2.1 


rejection of requests following non-200OK 
responses including encrypted SDP offers? 


Clause 6.3, second 
paragraph 







23.3 


handling of 200OK responses including SDP 
offers? 


Clause 6.2, third 
paragraph 


m 




23.3.1 


session termination on receipt of encrypted SDP 
offers in 200OK responses? 


Clause 6.2, third 
paragraph 







CPC parameter definition (Annex J) 


24 


procedures at the S-CSCF at the terminating 
network 


Clause J.9A 


m 




Additionai procedures in support of UE managed NAT traversal (Annex K) 


25.1 


additional procedures to initial registration and 
user-initiated re-registration using unprotected 
REGISTER for UE managed NAT traversal? 


Clauses 5.4.1.2.1, 
K.2.3.2.1 


m 




25.2 


additional procedures to initial registration and 
user-initiated re-registration using protected 
REGISTER for UE managed NAT traversal? 


Clauses 5.4.1.2.2, 
K.2.3.2.2 


m 




26 


additional procedures to handling requests 
terminated by the served user for UE managed 
NAT traversal? 


Clauses 5.4.3.3, 
K.2.3.3 


m 




SIP digest (Annex L) 


27.1 


additional procedures to initial registration and 
user-initiated re-registration using unprotected 
REGISTER for SIP digest? 


Clauses 5.4.1.2.1, 
L.2.3.1.1 and 
L.2.3.1.3 


m 




27.2 


additional procedures to initial registration and 
user-initiated re-registration using protected 
REGISTER for SIP digest? 


Clauses 5.4.1.2.2, 

L.2.3.1.2and 

L.2.3.1.3 


m 




28 


additional procedures to User-initiated 
deregistration for SIP digest? 


Clauses 5.4.1.4, 
L.2.3.2 


m 




29 


additional procedures to handling of the receipt of 
UE-initiated requests (other than REGISTER) for 
SIP digest? 


Clauses 5.4.3, 
L.2.3.4 







29.1 


In case of mismatch of the received with the registered public user identity (Clause L.2. 3.4.1 2) ... 


29.1.1 


reject the request with a 400 response? 


Clause L.2.3.4.1 2) 
option before "or" 


C.2 




29.1.2 


silently discard the request? 


Clause L.2.3.4.1 2) 
option after "or" 


C.2 





ETSI 



23 



ETSI TS 102 790-1 VI. 1.1 (2010-03) 



Item 



Major capability: 
Does the implementation support.. 



Reference 



Status 



Support 



NOTE: 



o.n 

0.1 



The S-CSCF shall provide the UA role when acting as registrar or notifier of event information, when 

providing a messaging mechanism by sending the MESSAGE method and when performing S-CSCF 

initiated dialog release. 

At least one of these capabilities shall be supported. 

0.3, if A.6/1 7.2.2 is supported, else n/a 



A.5.4.2 S-CSCF header handling 



Table A.7: S-CSCF Header Handling 



Item 


Header handling: 
Does the implementation support... 


Reference 


Status 


Support 


1 


the Path header in REGISTER request and 
related 200OK response messages? 


Clause 5.4.1.1 


m 




2 


the Service-Route header in 200OK response 
messages to REGISTER requests? 


Clause 5.4.1.1 


m 





A.5.5 IBCF Role 

The tables provided in this clause need only to be completed for IBCF implementations, where item A. 2/4 above is 
supported. 



A.5.5.1 IBCF Capabilities 



Table A.8: IBCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


the proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.10 


m 




1.2 


the proxy role with IMS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.7 


m 




2 


provision of application level gateway functionality? 


Clause 4.1 







3 


provision of screening functionality? 


Clause 4.1 







4.1 


the UA role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.10 


C.I 




4.2 


the UA role with IMS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.7 


C.I 




5.1 


the loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




5.2 


interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] and 
clauses 12.2.1.1, 
16.4 


m 




IBCF specific application usage of SIP (clause 5. 10) 


6 


procedures that apply on receipt of a REGISTER 
request when acting as exit point? 


Clause 5.10.2.1 


m 




7 


procedures that apply on receipt of a initial 
requests (other than REGISTER) when acting as 
exit point? 


Clause 5.10.2.2 


m 




7.1 


application of periodic session refreshment on 
receipt of INVITE requests when acting as exit 
point? 


Clause 5.10.2.2 







8 


procedures that apply on receipt of a subsequent 
requests (other than REGISTER) when acting as 
exit point? 


Clause 5.10.2.3 


m 




9.1 


provision of transport plane control functionality? 


Clauses 5.10.2.4, 
5.10.3.4 
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Item 


IVIajor capability: 
Does the implementation support... 


Reference 


Status 


Support 


9.2 


IBCF-initiated call release in case of receipt of an 
indication of a transport plane related error? 


Clauses 5.10.2.4, 
5.10.3.4 







10 


procedures that apply on receipt of a REGISTER 
request when acting as entry point? 


Clause 5.10.3.1 


m 




11 


procedures that apply on receipt of a initial 
requests (other than REGISTER) when acting as 
entry point? 


Clause 5.10.3.2 


m 




11.1 


application of periodic session refreshment on 
receipt of INVITE requests when acting as entry 
point? 


Clause 5.10.3.2 







12 


procedures that apply on receipt of a subsequent 
requests (other than REGISTER) when acting as 
entry point) when acting as entry point? 


Clause 5.10.2.3 


m 




13 


procedures for network topology hiding? 


Clause 5.10.4 


m 




13.1 


inclusion of a direction identifier to the SIP URI? 


Clauses 5.10.4.1, 
5.102.1 and 5.10.3.1 







13.2 


encryption for network topology hiding? 


Clause 5.10.4.2 


m 




13.3 


decryption for network topology hiding? 


Clause 5.10.4.3 


m 




14 


IMS-ALG functionality? 


Clauses 5.10.5, 6.7 







15.1 


B2BUA functionality when performing screening of 
the SIP signalling? 


Clauses 5.10.6.1, 
5.10.5 







15.2 


omission or modification of received SIP headers 
prior to forwarding SIP messages? (see note) 


Clause 5.10.6.2 







15.3 


omission or modification of received SDP bodies 
prior to forwarding SIP messages? 


Clause 5.10.6.3 







NOTE: The modification of the following headers is discouraged by ES 283 003 [1]: Authorization, 
www-Authenticate, Path and Service-Route headers. 



A.5.6 E-CSCF Role 

The tables provided in this clause need only to be completed for E-CSCF implementations, where item A.2/5 above is 
supported. 



ETSI 



25 



ETSI TS 102 790-1 VI. 1.1 (2010-03) 



A.5.6.1 E-CSCF Capabilities 



Table A.9: E-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


the proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.11 


m 




1.2 


the UA role when providing server functionality to 
return a final response? 


Clause 4.1 







2.1 


the loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




2.2 


interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] and 
clauses 12.2.1.1, 
16.4 


m 




E-CSCF specific application usage of SIP (clause 5. 1 1) 


3.1 


acceptance and onwards routeing of requests for 
emergency services? 


Clause 5.11.2 


m 




3.2 


rejection and onwards routeing of requests for 
non-emergency services? (see note) 


Clause 5.1 1.2 


m 




3.3 


insertion of previously saved values into the 
P-Charging-Vector and P-Charging-Function 

header of requests and responses (other than 
CANCEL and ACK) to be forwarded? 


Clause 5.1 1.2 







3.4 


application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.1 1.2 







NOTE: Request for emergency services contain an URN with a top-level service type of "sos". 
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